The present invention relates generally to systems and methods that enable multiple-access of the same channel in a network, and, more particularly, to a system and method of timestamp synchronization in a network that employs a reservation-based TDMA protocol.
In general, communications networks, particularly wireless networks, typically employ a multiple-access protocol that is designed to prevent collisions of data packets due to simultaneous transmission of the data packets by multiple transmitters in the network using the same channel. One protocol that has come into widespread use is known as Time-Division Multiple Access (TDMA). A detailed description of this technique can be found in the reference book Telecommunications Networks: Protocols, Modeling and Analysis, Addison-Wesley, 1997. In general, in accordance with the TDMA protocol, channel time is divided into small time slots, each of which is assigned to a different node (user). This time slot assignment can either be fixed (classical TDMA), or variable (reservation-based TDMA). In either case, since the number of nodes (users) is finite the data is usually transmitted in TDMA xe2x80x9cframesxe2x80x9d, which ensure that the delays encountered by the different users are finite.
For example, in fixed-assignment TDMA, the TDMA frame consists of the total number of slots assigned to all users, after which the TDMA frame repeats. In the case of reservation-based TDMA, a natural framing occurs in terms of different xe2x80x9cphasesxe2x80x9d of the TDMA frame, consisting typically of a xe2x80x9ccontrolxe2x80x9d phase in which reservations are requested and assigned, and a xe2x80x9cdataxe2x80x9d phase in which the data is transmitted by the different users in their respective assigned time slots.
It is necessary that all transmitters and receivers in the TDMA network be synchronized in terms of the TDMA frame. An incorrectly synchronized transceiver, at best, cannot communicate, but, at worst, can cause the entire TDMA network to collapse if appropriate safeguards are not built into the protocol. It should be recognized that TDMA frame synchronization is not the same as clock synchronization of a modem, which is a function of the Physical layer. Usually, frame synchronization is achieved using a centralized control strategy implemented by a central controller (CC). However, frame synchronization can also be implemented in a distributed fashion.
In most TDMA networks, a universal time reference is required to properly allocate resources for transmission. This universal time reference is usually provided in the form of a xe2x80x9ctimestampxe2x80x9d, e.g., which specifies the current time, such as 2 p.m. The timestamps are broadcast periodically by the central controller, and are used by the end terminals (ETs) to synchronize their xe2x80x9ctimestampxe2x80x9d registers.
For variable-sized TDMA frames, synchronization achieved through the use of timestamps typically requires the utilization of a phase-locked loop (PLL) in each of the ETs, which can be quite complex. Further, the PLLs used for this purpose must be redesigned whenever the parameters of the timestamp scheme are changed, for example, when the frequency of timestamp transmission is changed. In this connection, a generic synchronization scheme is desired in order to enable an ET to be used interchangeably within many different networks.
With presently known frame synchronization techniques, the timestamp values are generated from a common clock. For example, in accordance with the IEEE 1394 standard, the clock distribution within a local 1394 serial bus is accomplished by means of the cycle master (or the central controller) periodically sending a cycle_start packet, which contains the current bus_time (or timestamp). This xe2x80x9cre-synchronizationxe2x80x9d is ideally performed every 125 ms. However, it is possible that the transmission of the cycle_start packet could be slightly delayed due to the local 1394 serial bus being used by another node when the cycle_start packet needs to be sent, thereby requiring the cycle master to wait until that node finishes its transmission before sending the cycle_start packet.
With reference now to FIG. 1, a method for generating the cycle start_packet at the 1394 cycle master will now be described. More particularly, a crystal 20 that runs at the master clock rate of 24.576 MHz is input to a cycle counter 22. Frame synchronization is achieved by synchronizing the cycle counters within all 1394 nodes interconnected by the local 1394 serial bus. The output of the cycle counter 22 is passed through a modulo 125 ms block 24 that sends a trigger signal to a state machine 26 every 125 ms, in response thereto. The state machine 26 then sends a channel request signal to the 1394 Physical (PHY) layer 28 in response to the trigger signal sent by the modulo 125 ms block 24. As soon as the channel becomes available, the 1394 PHY layer 28 sends back a channel available signal to the state machine 26. In response to the channel available signal, the state machine 26 prepares the packet header for the cycle_start packet, and sends an enable signal to a register 30 to latch the contents of the cycle counter 22 at the proper instant to generate the current bus_time (timestamp value). Any delay in processing can be easily taken into account by properly delaying the enable signal to the register 30 by the amount of the processing delay.
At the receiver (i.e., each node that receives the cycle_start packet), the cycle counter in that node must be set to the appropriate bus_time received via the cycle_start packet. A method for accomplishing this task will now be described with reference to FIG. 2. More particularly, the PHY layer 33 of the receiver node receives the cycle_start packet and sends it to the link layer, which includes a decode cycle_start header block 35 for decoding the cycle_start packet header to ensure that it is indeed the cycle_start packet. Simultaneously, the bus_time value is extracted from the cycle_start packet and loaded into a register 37. A processing delay block 39 adds any processing delay (for the decoding operation and/or for the loading of the bus_time value into the register 37) to either the output of the register 37, or to a load signal output by the decode cycle_start header block 35. The load signal is applied to the load terminal of the cycle counter 41 of that receiver node to enable the loading of the sum of the contents of the register 37 and the processing delay into the cycle counter 41.
It should be recognized that it is extremely important to be cycle-accurate while resetting the cycle counter 41, which means that the bus_time transmitted by the cycle master must correspond to the exact time that the cycle_start packet is sent, and that the processing delay in each receiver node must be very precisely determined.
The resetting of the cycle counter 41 every 125 ms ensures that the clocks obtained from different crystals do not drift significantly with respect to each other. Most protocols have an interval during which the timestamp update must be sent. Otherwise, the timing jitter may be larger than what can be handled by a particular application, e.g., an MPEG decoder.
IEEE 802.11 has a similar protocol. More particularly, in accordance with the IEEE 802.11 standard, xe2x80x9cbeaconsxe2x80x9d are periodically broadcast, in a manner similar to the broadcast of the cycle_start packet in accordance with the IEEE 1394 standard. The beacon contains, among other fields, the timestamp value and the timestamp interval. The timestamp interval is flexible with the IEEE 802.11 standard, as contrasted to the fixed 125 ms cycle time with the IEEE 1394 standard. As with the IEEE 1394 standard, the beacon transmission can be delayed if the channel is not immediately available. As with the IEEE 1394 standard, the key requirement is that the timestamp value must correspond to the exact time of transmission of the beacon packet.
It should be recognized that both IEEE 1394 and IEEE 802.11 are not reservation-based protocols. In both cases, an arbitration phase is first initiated to determine access for a particular receiver node. Even the cycle_start and beacon packets must first arbitrate the use of the channel prior to transmission.
For a reservation-based TDMA protocol, there are many problems with the timestamp-based approach. The first problem is that the transmission of the timestamp value must also be reserved, and subsequently, other data must also be queued for transmission. In order to ensure efficient use of processor resources (which must be used for managing many other functions), this queuing is usually scheduled in advance. However, the timestamp value cannot be obtained until the exact time of transmission. Further, the queuing of the data packets behind the timestamp value cannot be done before the timestamp value is obtained. Of course, it is possible to switch the data stream between two separate queues with one holding the timestamp value and the other holding the data. However, this solution is quite complicated and requires precise synchronization.
A more detailed understanding of this problem can be gained by considering the case of a wireless asynchronous transfer mode (ATM) network that uses a reservation-based medium-access control (MAC) protocol. The MAC protocol implementation depends on a periodic control-data-frame (CDF), as described by C. Y. Ngo and S. N. Hulyalkar in ADetailed MAC Sub-System Description for BS-Oriented WATM LAN@, WP3, D3.1, Aug. 15, 1996. Each CDF contains many phases, during which both control and data information is sent from both the base station (BS) and the wireless terminal (WT). FIG. 3 illustrates four phases for implementing such a generic structure, namely, BS_SIG; DN_DATA; UP_DATA; and, E_BURST. A brief description of each of these phases follows:
BS_SIG: During this phase, the BS sends control information for the downlink. The timestamp packet can be assumed to be sent during this phase. At the BS, the processor starts the transmission of packets from BS. At the WT, the WT starts the process of reception of packets from the BS.
DN_DATA: During this phase, the BS sends data packets for the WTs. At the BS, the processor is busy interpreting the packets sent by the WT during the UP_DATA phase. At the WT, the processor is busy storing the PHY FIFO for the next burst of transmission during the UP_DATA phase.
UP_DATA: During this phase, the WT sends data and signaling packets for the BS. Signaling is sent using superslots. At the BS, the processor is busy storing the PHY FIFO for the next burst of transmission during the BS_SIG and DN_DATA phases. At the WT, the processor is busy interpreting the packets sent by the BS during the BS_SIG and the DN_DATA phases.
E_BURST: During this phase, the WTs, which have not currently been allocated space for transmission during the UP_DATA phase, indicate whether they want to enter the WATM network. Both the WT and the BS processors are busy implementing the E_BURST phase.
The hardware design is based on the BS and each WT keeping the same timestamp values as a basis for computing the four phases of a CDF. All must maintain the same time periods in order to communicate and transfer packets effectively. All must synchronize their timestamps periodically, by copying the base station value, and all must take starting time directives from the BS.
The MAC processor is assumed to be interrupt-driven for both the WTs and the BS. The BS determines the timing for the entire system. Using the timestamp value as a reference, it determines the exact time when each of the phases operates. This timing information is sent during the BS_SIG_n phase. Since all phases are successive to each other, the WT and the BS set up a counter for the next phase based on the timing information, which then triggers an interrupt to the processor when the counter overflows. The processor must finish its functions during the respective phase within the time allotted and be prepared for the next phase.
For timestamp synchronization, the BS can be assumed to send a timestamp value during the BS_SIG phase. However, note that the BS is busy storing the PHY_FIFO with the packets intended for transmission during the BS_SIG and DN_DATA phases. However, the timestamp value must be determined during the BS_SIG phase and cannot be obtained during the UP_DATA phase. Consequently, the normal transmission stream must be stopped to allow for the timestamp value to be loaded from the timestamp register during the time of transmission. This solution is not desirable since it conflicts with the direct data path.
It should be appreciated that the problem described above is not due to the particular protocol considered, but is generally due to the reservation-based nature of the protocol, whereby decisions on what is transmitted at particular times are made in advance of those times.
One solution to this problem is to send only a timestamp packet during the BS_SIG phase. But for wireless ATM, which uses a 53-byte cell, this is a waste of resources, since a timestamp value may be only 4 bytes. More generally, the use of a fixed slot for transmission of only timestamp information results in a waste of network resources. In this connection, it should be recognized that this fixed slot is an intrinsic aspect of any reservation-based protocol, because without the xe2x80x9csmallestxe2x80x9d slotting, it is not possible to reserve any channel time. The problem arises due to the fact that the smallest time slot is still significantly greater than the time required to send only the timestamp value.
Based on the above and foregoing, it can be appreciated that there presently exists a need in the art for a method of timestamp synchronization in a reservation-based TDMA-protocol network that overcomes the above-described drawbacks and shortcomings of the presently available technology. The present invention fulfills this need in the art.
The present invention encompasses a method for synchronizing timestamps in a network (e.g., a wireless ATM network) that includes a control node and a plurality of other nodes that communicate with one another over a common channel mediated by a medium-access control subsystem (e.g., one that uses a reservation-based TDMA protocol). The method includes the steps of sending a first command from the control node, at a first time, then storing a starting timestamp value in a register within the control node and each of the other nodes, in response to the first command, and then sending a second command from the control node, at a second time later than the first time. Each of the other nodes computes the difference between the starting timestamp value and a current timestamp value, and then adds the computed difference to the current timestamp value. In an alternative embodiment, the control node sends a preset command and each of the other nodes presets their respective timestamp to a prescribed initial timestamp value, in response to the preset command. Each of the nodes periodically compares a current timestamp counter value with a prescribed reset value, and upon detecting a coincidence, sets a sync flag latch to indicate that a next timestamp value correction is to be made, in response to a next preset command.
The present invention also encompasses networks that implement the above-described methods.